1. Introduction
1.1. Introduction
WebAssembly (abbreviated Wasm [1]) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.
WebAssembly is an open standard developed by a W3C Community Group.
This document describes version 3.0 (2025-09-24) of the core WebAssembly standard. It is intended that it will be superseded by new incremental releases with additional features in the future.
1.1.1. Design Goals
The design goals of WebAssembly are the following:
-
Fast, safe, and portable semantics:
-
Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.
-
Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.
-
Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.
-
Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.
-
Language-independent: does not privilege any particular language, programming model, or object model.
-
Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.
-
Open: programs can interoperate with their environment in a simple and universal manner.
-
-
Efficient and portable representation:
-
Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.
-
Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.
-
Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.
-
Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.
-
Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.
-
Portable: makes no architectural assumptions that are not broadly supported across modern hardware.
-
WebAssembly code is also intended to be easy to inspect and debug, especially in environments like web browsers, but such features are beyond the scope of this specification.
1.1.2. Scope
At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). As such, it has many use cases and can be embedded in many different environments. To encompass their variety and enable maximum reuse, the WebAssembly specification is split and layered into several documents.
This document is concerned with the core ISA layer of WebAssembly. It defines the instruction set, binary encoding, validation, and execution semantics, as well as a textual representation. It does not, however, define how WebAssembly programs can interact with a specific environment they execute in, nor how they are invoked from such an environment.
Instead, this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.
1.1.3. Security Considerations
WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.
Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.
1.1.4. Dependencies
WebAssembly depends on two existing standards:
-
[IEEE-754-2019], for the representation of floating-point data and the semantics of respective numeric operations.
-
[UNICODE], for the representation of import/export names and the text format.
However, to make this specification self-contained, relevant aspects of the aforementioned standards are defined and formalized as part of this specification, such as the binary representation and rounding of floating-point values, and the value range and UTF-8 encoding of Unicode characters.
Note
The aforementioned standards are the authoritative source of all respective definitions. Formalizations given in this specification are intended to match these definitions. Any discrepancy in the syntax or semantics described is to be considered an error.
1.2. Overview
1.2.1. Concepts
WebAssembly encodes a low-level, assembly-like programming language. This language is structured around the following concepts.
- Values
-
WebAssembly provides only four basic number types. These are integers and [IEEE-754-2019] numbers, each in 32 and 64 bit width. 32-bit integers also serve as Booleans and as memory addresses. The usual operations on these types are available, including the full matrix of conversions between them. There is no distinction between signed and unsigned integer types. Instead, integers are interpreted by respective operations as either unsigned or signed in two’s complement representation.
In addition to these basic number types, there is a single 128 bit wide vector type representing different types of packed data. The supported representations are four 32-bit, or two 64-bit [IEEE-754-2019] numbers, or different widths of packed integer values, specifically two 64-bit integers, four 32-bit integers, eight 16-bit integers, or sixteen 8-bit integers.
Finally, values can consist of opaque references that represent pointers towards different sorts of entities. Unlike with other types, their size or representation is not observable.
- Instructions
-
The computational model of WebAssembly is based on a stack machine. Code consists of sequences of instructions that are executed in order. Instructions manipulate values on an implicit operand stack [1] and fall into two main categories. Simple instructions perform basic operations on data. They pop arguments from the operand stack and push results back to it. Control instructions alter control flow. Control flow is structured, meaning it is expressed with well-nested constructs such as blocks, loops, and conditionals. Branches can only target such constructs.
- Traps
-
Under some conditions, certain instructions may produce a trap, which immediately aborts execution. Traps cannot be handled by WebAssembly code, but are reported to the outside environment, where they typically can be caught.
- Functions
-
Code is organized into separate functions. Each function takes a sequence of values as parameters and returns a sequence of values as results. Functions can call each other, including recursively, resulting in an implicit call stack that cannot be accessed directly. Functions may also declare mutable local variables that are usable as virtual registers.
- Tables
-
A table is an array of opaque values of a particular reference type. It allows programs to select such values indirectly through a dynamic index operand. Thereby, for example, a program can call functions indirectly through a dynamic index into a table. This allows emulating function pointers by way of table indices.
- Linear Memory
-
A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.
- Modules
-
A WebAssembly binary takes the form of a module that contains definitions for functions, tables, and linear memories, as well as mutable or immutable global variables. Definitions can also be imported, specifying a module/name pair and a suitable type. Each definition can optionally be exported under one or more names. In addition to definitions, modules can define initialization data for their memories or tables that takes the form of segments copied to given offsets. They can also define a start function that is automatically executed.
- Embedder
-
A WebAssembly implementation will typically be embedded into a host environment. This environment defines how loading of modules is initiated, how imports are provided (including host-side definitions), and how exports can be accessed. However, the details of any particular embedding are beyond the scope of this specification, and will instead be provided by complementary, environment-specific API definitions.
In practice, implementations need not maintain an actual operand stack. Instead, the stack can be viewed as a set of anonymous registers that are implicitly referenced by instructions. The type system ensures that the stack height, and thus any referenced register, is always known statically.
1.2.2. Semantic Phases
Conceptually, the semantics of WebAssembly is divided into three phases. For each part of the language, the specification specifies each of them.
- Decoding
-
WebAssembly modules are distributed in a binary format. Decoding processes that format and converts it into an internal representation of a module. In this specification, this representation is modelled by abstract syntax, but a real implementation could compile directly to machine code instead.
- Validation
-
A decoded module has to be valid. Validation checks a number of well-formedness conditions to guarantee that the module is meaningful and safe. In particular, it performs type checking of functions and the instruction sequences in their bodies, ensuring for example that the operand stack is used consistently.
- Execution
-
Finally, a valid module can be executed. Execution can be further divided into two phases:
Instantiation. A module instance is the dynamic representation of a module, complete with its own state and execution stack. Instantiation executes the module body itself, given definitions for all its imports. It initializes globals, memories and tables and invokes the module’s start function if defined. It returns the instances of the module’s exports.
Invocation. Once instantiated, further WebAssembly computations can be initiated by invoking an exported function on a module instance. Given the required arguments, that executes the respective function and returns its results.
Instantiation and invocation are operations within the embedding environment.
2. Structure
2.1. Conventions
WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure. For conciseness, this structure is described in the form of an abstract syntax. All parts of this specification are defined in terms of this abstract syntax.
2.1.1. Grammar Notation
The following conventions are adopted in defining grammar rules for abstract syntax.
-
Terminal symbols (atoms) are written in sans-serif font or in symbolic form: , , , .
-
Nonterminal symbols are written in italic font: , .
-
is a sequence of iterations of .
-
is a possibly empty sequence of iterations of . (This is a shorthand for used where is not relevant.)
-
is a non-empty sequence of iterations of . (This is a shorthand for where .)
-
is an optional occurrence of . (This is a shorthand for where .)
-
Productions are written .
-
Large productions may be split into multiple definitions, indicated by ending the first one with explicit ellipses, , and starting continuations with ellipses, .
-
Some productions are augmented with side conditions, “”, that provide a shorthand for a combinatorial expansion of the production into many separate cases.
-
If the same meta variable or non-terminal symbol appears multiple times in a production, then all those occurrences must have the same instantiation. (This is a shorthand for a side condition requiring multiple different variables to be equal.)
2.1.2. Auxiliary Notation
When dealing with syntactic constructs the following notation is also used:
-
denotes the empty sequence.
-
denotes the length of a sequence .
-
denotes the -th element of a sequence , starting from .
-
denotes the sub-sequence of a sequence .
-
denotes the same sequence as , except that the -th element is replaced with .
-
denotes the same sequence as , except that the sub-sequence is replaced with .
-
denotes the sequence concatenated with ; this is equivalent to , but used for clarity.
-
denotes the flattened sequence, formed by concatenating all sequences in .
-
denotes that is a member of the sequence , that is, is of the form for some sequences , .
Moreover, the following conventions are employed:
-
The notation , where is a non-terminal symbol, is treated as a meta variable ranging over respective sequences of (similarly for , , ).
-
When given a sequence , then the occurrences of in an iterated sequence are assumed to denote the individual elements of , respectively (similarly for , , ). This implicitly expresses a form of mapping syntactic constructions over a sequence.
-
denotes the same sequence as , but implicitly also defines to be the sequence of values to .
Note
For example, if is the sequence , then denotes the sequence .
The form additionally gives access to an index variable inside the iteration. For example, denotes the sequence .
Productions of the following form are interpreted as records that map a fixed set of fields to “values” , respectively:
The following notation is adopted for manipulating such records:
-
Where the type of a record is clear from context, empty fields with value are often omitted.
-
denotes the contents of the component of .
-
denotes the same record as , except that the value of the component is replaced with .
-
denotes the same record as , except that is appended to the sequence value of the component, that is, it is short for .
-
denotes the composition of two identically shaped records by concatenating each field of sequences point-wise:
-
denotes the composition of a sequence of records, respectively; if the sequence is empty, then all fields of the resulting record are empty.
The update notation for sequences and records generalizes recursively to nested components accessed by “paths” :
-
is short for ,
-
is short for .
2.1.3. Lists
Lists are bounded sequences of the form (or ), where the can either be values or complex constructions. A list can have at most elements.
2.2. Values
WebAssembly programs operate on primitive numeric values. Moreover, in the definition of programs, immutable sequences of values occur to represent more complex data, such as text strings or other vectors.
2.2.1. Bytes
The simplest form of value are raw uninterpreted bytes. In the abstract syntax they are represented as hexadecimal literals.
2.2.1.1. Conventions
-
The meta variable ranges over bytes.
-
Bytes are sometimes interpreted as natural numbers .
2.2.2. Integers
Different classes of integers with different value ranges are distinguished by their bit width and by whether they are unsigned or signed.
The class defines uninterpreted integers, whose signedness interpretation can vary depending on context. In the abstract syntax, they are represented as unsigned values. However, some operations convert them to signed based on a two’s complement interpretation.
Note
The main integer types occurring in this specification are , , , and . However, other sizes occur as auxiliary constructions, e.g., in the definition of floating-point numbers.
2.2.2.1. Conventions
-
The meta variables , , , range over integers.
-
Numbers may be denoted by simple arithmetics, as in the grammar above. In order to distinguish arithmetics like from sequences like , the latter is distinguished with parentheses.
2.2.3. Floating-Point
Floating-point data represents 32 or 64 bit values that correspond to the respective binary formats of the [IEEE-754-2019] standard (Section 3.3).
Every value has a sign and a magnitude. Magnitudes can either be expressed as normal numbers of the form , where is the exponent and is the significand whose most significant bit is , or as a subnormal number where the exponent is fixed to the smallest possible value and is ; among the subnormals are positive and negative zero values. Since the significands are binary values, normals are represented in the form in the abstract syntax, where is the bit width of ; similarly for subnormals.
Possible magnitudes also include the special values (infinity) and (NaN, not a number). NaN values have a payload that describes the mantissa bits in the underlying binary representation. No distinction is made between signalling and quiet NaNs.
where and with
A canonical NaN is a floating-point value where is a payload whose most significant bit is while all others are :
An arithmetic NaN is a floating-point value with , such that the most significant bit is while all others are arbitrary.
Note
In the abstract syntax, subnormals are distinguished by the leading of the significand. The exponent of subnormals has the same value as the smallest possible exponent of a normal number. Only in the binary representation the exponent of a subnormal is encoded differently than the exponent of any normal number.
The notion of canonical NaN defined here is unrelated to the notion of canonical NaN that the [IEEE-754-2019] standard (Section 3.5.2) defines for decimal interchange formats.
2.2.3.1. Conventions
-
The meta variable ranges over floating-point values where clear from context.
-
Where clear from context, shorthands like denote floating point values like .
2.2.4. Vectors
Numeric vectors are 128-bit values that are processed by vector instructions (also known as SIMD instructions, single instruction multiple data). They are represented in the abstract syntax using . The interpretation of lane types (integer or floating-point numbers) and lane sizes are determined by the specific instruction operating on them.
2.2.5. Names
Names are sequences of characters, which are scalar values as defined by [UNICODE] (Section 2.4).
Due to the limitations of the binary format, the length of a name is bounded by the length of its UTF-8 encoding.
2.2.5.1. Convention
-
Characters (Unicode scalar values) are sometimes used interchangeably with natural numbers .
2.3. Types
Various entities in WebAssembly are classified by types. Types are checked during validation, instantiation, and possibly execution.
2.3.1. Number Types
Number types classify numeric values.
The types and classify 32 and 64 bit integers, respectively. Integers are not inherently signed or unsigned, their interpretation is determined by individual operations.
The types and classify 32 and 64 bit floating-point data, respectively. They correspond to the respective binary floating-point representations, also known as single and double precision, as defined by the [IEEE-754-2019] standard (Section 3.3).
Number types are transparent, meaning that their bit patterns can be observed. Values of number type can be stored in memories.
2.3.1.1. Conventions
-
The notation denotes the bit width of a number type . That is, and .
2.3.2. Vector Types
Vector types classify vectors of numeric values processed by vector instructions (also known as SIMD instructions, single instruction multiple data).
The type corresponds to a 128 bit vector of packed integer or floating-point data. The packed data can be interpreted as signed or unsigned integers, single or double precision floating-point values, or a single 128 bit type. The interpretation is determined by individual operations.
Vector types, like number types are transparent, meaning that their bit patterns can be observed. Values of vector type can be stored in memories.
2.3.2.1. Conventions
-
The notation for bit width extends to vector types as well, that is, .
2.3.3. Type Uses
A type use is the use site of a type index referencing a composite type defined in a module. It classifies objects of the respective type.
The syntax of type uses is extended with additional forms for the purpose of specifying validation and execution.
2.3.4. Heap Types
Heap types classify objects in the runtime store. There are three disjoint hierarchies of heap types:
-
function types classify functions,
-
aggregate types classify dynamically allocated managed data, such as structures, arrays, or unboxed scalars,
-
external types classify external references possibly owned by the embedder.
The values from the latter two hierarchies are interconvertible by ways of the and instructions. That is, both type hierarchies are inhabited by an isomorphic set of values, but may have different, incompatible representations in practice.
A heap type is either abstract or concrete. A concrete heap type consists of a type use that classifies an object of the respective type defined in a module. Abstract types are denoted by individual keywords.
The type denotes the common supertype of all function types, regardless of their concrete definition. Dually, the type denotes the common subtype of all function types, regardless of their concrete definition. This type has no values.
The type denotes the common supertype of all exception references. This type has no concrete subtypes. Dually, the type denotes the common subtype of all forms of exception references. This type has no values.
The type denotes the common supertype of all external references received through the embedder. This type has no concrete subtypes. Dually, the type denotes the common subtype of all forms of external references. This type has no values.
The type denotes the common supertype of all aggregate types, as well as possibly abstract values produced by internalizing an external reference of type . Dually, the type denotes the common subtype of all forms of aggregate types. This type has no values.
The type is a subtype of that includes all types for which references can be compared, i.e., aggregate values and .
The types and denote the common supertypes of all structure and array aggregates, respectively.
The type denotes unboxed scalars, that is, integers injected into references. Their observable value range is limited to 31 bits.
Note
Values of type are not actually allocated in the store, but represented in a way that allows them to be mixed with actual references into the store without ambiguity. Engines need to perform some form of pointer tagging to achieve this, which is why one bit is reserved. Since this type is to be reliably unboxed on all hardware platforms supported by WebAssembly, it cannot be wider than 32 bits minus the tag bit.
Although the types , , , and are not inhabited by any values, they can be used to form the types of all null references in their respective hierarchy. For example, is the generic type of a null reference compatible with all function reference types.
The syntax of abstract heap types is extended with additional forms for the purpose of specifying validation and execution.
2.3.5. Reference Types
Reference types classify values that are first-class references to objects in the runtime store.
A reference type is characterised by the heap type it points to.
In addition, a reference type of the form is nullable, meaning that it can either be a proper reference to or null. Other references are non-null.
Reference types are opaque, meaning that neither their size nor their bit pattern can be observed. Values of reference type can be stored in tables but not in memories.
2.3.5.1. Conventions
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
-
The reference type is an abbreviation for .
2.3.6. Value Types
Value types classify the individual values that WebAssembly code can compute with and the values that a variable accepts. They are either number types, vector types, or reference types.
The syntax of value types is extended with additional forms for the purpose of specifying validation.
2.3.6.1. Conventions
-
The meta variable ranges over value types or subclasses thereof where clear from context.
2.3.7. Result Types
Result types classify the result of executing instructions or functions, which is a sequence of values, written with brackets.
2.3.8. Block Types
Block types classify the input and output of structured control instructions delimiting blocks of instructions.
They are given either as a type index that refers to a suitable function type reinterpreted as an instruction type, or as an optional value type inline, which is a shorthand for the instruction type .
2.3.9. Composite Types
Composite types are all types composed from simpler types, including function types, structure types and array types.
Function types classify the signature of functions, mapping a list of parameters to a list of results. They are also used to classify the inputs and outputs of instructions.
Aggregate types like structure or array types consist of a list of possibly mutable, possibly packed field types describing their components. Structures are heterogeneous, but require static indexing, while arrays need to be homogeneous, but allow dynamic indexing.
2.3.9.1. Conventions
-
The notation for the bit width of a value type extends to packed types as well, that is, and .
-
The auxiliary function maps a storage type to the value type obtained when accessing a field:
2.3.10. Recursive Types
Recursive types denote a group of mutually recursive composite types, each of which can optionally declare a list of type uses of supertypes that it matches. Each type can also be declared final, preventing further subtyping.
In a module, each member of a recursive type is assigned a separate type index.
2.3.11. Address Types
Address types are a subset of number types that classify the values that can be used as offsets into memories and tables.
2.3.11.1. Conventions
The minimum of two address types is defined as the address type whose bit width is the minimum of the two.
2.3.12. Limits
Limits classify the size range of resizeable storage associated with memory types and table types.
If no maximum is present, then the respective storage can grow to any valid size.
2.3.13. Tag Types
Tag types classify the signature tags with a type use referring to the definition of a function type that declares the types of parameter and result values associated with the tag. The result type is empty for exception tags.
2.3.14. Global Types
Global types classify global variables, which hold a value and can either be mutable or immutable.
2.3.15. Memory Types
Memory types classify linear memories and their size range.
The limits constrain the minimum and optionally the maximum size of a memory. The limits are given in units of page size.
2.3.16. Table Types
Table types classify tables over elements of reference type within a size range.
Like memories, tables are constrained by limits for their minimum and optionally maximum size. The limits are given in numbers of entries.
2.3.17. Data Types
Data types classify data segments. Since the contents of a data segment requires no further classification, they merely consist of a universal marker indicating well-formedness.
2.3.18. Element Types
Element types classify element segments by the reference type of its elements.
2.3.19. External Types
External types classify imports and external addresses with their respective types.
For functions, the type use has to refer to the definition of a function type.
Note
Future versions of WebAssembly may have additional uses for tags, and may allow non-empty result types in the function types of tags.
2.3.19.1. Conventions
The following auxiliary notation is defined for sequences of external types. It filters out entries of a specific kind in an order-preserving fashion:
2.4. Instructions
WebAssembly code consists of sequences of instructions. Its computational model is based on a stack machine in that instructions manipulate values on an implicit operand stack, consuming (popping) argument values and producing or returning (pushing) result values.
In addition to dynamic operands from the stack, some instructions also have static immediate arguments, typically indices or type annotations, which are part of the instruction itself.
Some instructions are structured in that they contain nested sequences of instructions.
The following sections group instructions into a number of different categories.
The syntax of instruction is further extended with additional forms for the purpose of specifying execution.
2.4.1. Parametric Instructions
Instructions in this group can operate on operands of any value type.
The instruction does nothing.
The instruction causes an unconditional trap.
The instruction simply throws away a single operand.
The instruction selects one of its first two operands based on whether its third operand is zero or not. It may include a value type determining the type of these operands. If missing, the operands must be of numeric or vector type.
Note
In future versions of WebAssembly, the type annotation on may allow for more than a single value being selected at the same time.
2.4.2. Control Instructions
Instructions in this group affect the flow of control.
The , , and instructions are structured instructions. They bracket nested sequences of instructions, called blocks. As the grammar prescribes, they must be well-nested.
A structured instruction can consume input and produce output on the operand stack according to its annotated block type.
Each structured control instruction introduces an implicit label. Labels are targets for branch instructions that reference them with label indices. Unlike with other index spaces, indexing of labels is relative by nesting depth, that is, label refers to the innermost structured control instruction enclosing the referring branch instruction, while increasing indices refer to those farther out. Consequently, labels can only be referenced from within the associated structured control instruction. This also implies that branches can only be directed outwards, “breaking” from the block of the control construct they target. The exact effect depends on that control construct. In case of or it is a forward jump, resuming execution after the end of the block. In case of it is a backward jump to the beginning of the loop.
Note
This enforces structured control flow. Intuitively, a branch targeting a or behaves like a statement in most C-like languages, while a branch targeting a behaves like a statement.
Branch instructions come in several flavors: performs an unconditional branch, performs a conditional branch, and performs an indirect branch through an operand indexing into the label list that is an immediate to the instruction, or to a default target if the operand is out of bounds. The and instructions check whether a reference operand is null and branch if that is the case or not the case, respectively. Similarly, and attempt a downcast on a reference operand and branch if that succeeds, or fails, respectively.
The instruction is a shortcut for an unconditional branch to the outermost block, which implicitly is the body of the current function. Taking a branch unwinds the operand stack up to the height where the targeted structured control instruction was entered. However, branches may additionally consume operands themselves, which they push back on the operand stack after unwinding. Forward branches require operands according to the output of the targeted block’s type, i.e., represent the values produced by the terminated block. Backward branches require operands according to the input of the targeted block’s type, i.e., represent the values consumed by the restarted block.
The instruction invokes another function, consuming the necessary arguments from the stack and returning the result values of the call. The instruction invokes a function indirectly through a function reference operand. The instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must contain function references. Since it may contain functions of heterogeneous type, the callee is dynamically checked against the function type indexed by the instruction’s second immediate, and the call is aborted with a trap if it does not match.
The , , and instructions are tail-call variants of the previous ones. That is, they first return from the current function before actually performing the respective call. It is guaranteed that no sequence of nested calls using only these instructions can cause resource exhaustion due to hitting an implementation’s limit on the number of active calls.
The instructions , , and are concerned with exceptions. The and instructions raise and reraise an exception, respectively, and transfers control to the innermost enclosing exception handler that has a matching catch clause. The instruction installs an exception handler that handles exceptions as specified by its catch clauses.
2.4.3. Variable Instructions
Variable instructions are concerned with access to local or global variables.
These instructions get or set the values of respective variables. The instruction is like but also returns its argument.
2.4.4. Table Instructions
Instructions in this group are concerned with tables table.
The and instructions load or store an element in a table, respectively.
The instruction returns the current size of a table. The instruction grows table by a given delta and returns the previous size, or if enough space cannot be allocated. It also takes an initialization value for the newly allocated entries.
The instruction sets all entries in a range to a given value. The instruction copies elements from a source table region to a possibly overlapping destination region; the first index denotes the destination. The instruction copies elements from a passive element segment into a table.
The instruction prevents further use of a passive element segment. This instruction is intended to be used as an optimization hint. After an element segment is dropped its elements can no longer be retrieved, so the memory used by this segment may be freed.
Note
An additional instruction that accesses a table is the control instruction .
2.4.5. Memory Instructions
Instructions in this group are concerned with linear memory.
Memory is accessed with and instructions for the different number types and vector types <syntax-vectype>. They all take a memory index and a memory argument that contains an address offset and the expected alignment (expressed as the exponent of a power of 2).
Integer loads and stores can optionally specify a storage size that is smaller than the bit width of the respective value type. In the case of loads, a sign extension mode is then required to select appropriate behavior.
Vector loads can specify a shape that is half the bit width of . Each lane is half its usual size, and the sign extension mode then specifies how the smaller lane is extended to the larger lane. Alternatively, vector loads can perform a splat, such that only a single lane of the specified storage size is loaded, and the result is duplicated to all lanes.
The static address offset is added to the dynamic address operand, yielding a 33-bit or 65-bit effective address that is the zero-based index at which the memory is accessed. All values are read and written in little endian byte order. A trap results if any of the accessed memory bytes lies outside the address range implied by the memory’s current size.
The instruction returns the current size of a memory. The instruction grows a memory by a given delta and returns the previous size, or if enough memory cannot be allocated. Both instructions operate in units of page size.
The instruction sets all values in a regionof a memory to a given byte. The instruction copies data from a source memory region to a possibly overlapping destination region in another or the same memory; the first index denotes the destination The instruction copies data from a passive data segment into a memory.
The instruction prevents further use of a passive data segment. This instruction is intended to be used as an optimization hint. After a data segment is dropped its data can no longer be retrieved, so the memory used by this segment may be freed.
2.4.6. Reference Instructions
Instructions in this group are concerned with accessing references.
The and instructions produce a null reference or a reference to a given function, respectively.
The instruction checks for null, while converts a nullable to a non-null one, and traps if it encounters null.
The compares two references.
The instructions and test the dynamic type of a reference operand. The former merely returns the result of the test, while the latter performs a downcast and traps if the operand’s type does not match.
Note
The and instructions provide versions of that branch depending on the success of failure of a null test instead of trapping. Similarly, the and instructions provides versions of that branch depending on the success of the downcast instead of trapping.
An additional instruction operating on function references is the control instruction .
2.4.7. Aggregate Instructions
Instructions in this group are concerned with creating and accessing references to aggregate types.
The instructions and allocate a new structure, initializing them either with operands or with default values. The remaining instructions on structs access individual fields, allowing for different sign extension modes in the case of packed storage types.
Similarly, arrays can be allocated either with an explicit initialization operand or a default value. Furthermore, allocates an array with statically fixed size, and and allocate an array and initialize it from a data or element segment, respectively. The instructions , , and access individual slots, again allowing for different sign extension modes in the case of a packed storage type; produces the length of an array; fills a specified slice of an array with a given value and , , and copy elements to a specified slice of an array from a given array, data segment, or element segment, respectively.
The instructions and convert between type and an unboxed scalar.
The instructions and allow lossless conversion between references represented as type and as .
2.4.8. Numeric Instructions
Numeric instructions provide basic operations over numeric values of specific type. These operations closely match respective operations available in hardware.
Numeric instructions are divided by number type. For each type, several subcategories can be distinguished:
-
Constants: return a static constant.
-
Unary Operations: consume one operand and produce one result of the respective type.
-
Binary Operations: consume two operands and produce one result of the respective type.
-
Tests: consume one operand of the respective type and produce a Boolean integer result.
-
Comparisons: consume two operands of the respective type and produce a Boolean integer result.
-
Conversions: consume a value of one type and produce a result of another (the source type of the conversion is the one after the “”).
Some integer instructions come in two flavors, where a signedness annotation distinguishes whether the operands are to be interpreted as unsigned or signed integers. For the other integer instructions, the use of two’s complement for the signed interpretation means that they behave the same regardless of signedness.
2.4.9. Vector Instructions
Vector instructions (also known as SIMD instructions, single instruction multiple data) provide basic operations over values of vector type.
Vector instructions have a naming convention involving a shape prefix that determines how their operands will be interpreted, written , and consisting of a lane type , a possibly packed numeric type, and its dimension , which denotes the number of lanes of that type. Operations are performed point-wise on the values of each lane.
Instructions prefixed with do not involve a specific interpretation, and treat the as either an value or a vector of individual bits.
Note
For example, the shape interprets the operand as four values, packed into an . The bit width of the lane type times always is .
Vector instructions can be grouped into several subcategories:
-
Constants: return a static constant.
-
Unary Operations: consume one operand and produce one result.
-
Binary Operations: consume two operands and produce one result.
-
Ternary Operations: consume three operands and produce one result.
-
Tests: consume one operand and produce a Boolean integer result.
-
Shifts: consume a operand and an operand, producing one result.
-
Splats: consume a value of numeric type and produce a result of a specified shape.
-
Extract lanes: consume a operand and return the numeric value in a given lane.
-
Replace lanes: consume a operand and a numeric value for a given lane, and produce a result.
Some vector instructions have a signedness annotation which distinguishes whether the elements in the operands are to be interpreted as unsigned or signed integers. For the other vector instructions, the use of two’s complement for the signed interpretation means that they behave the same regardless of signedness.
2.4.9.1. Conventions
-
The function extracts the lane type of a shape.
-
The function extracts the dimension of a shape.
-
The function extracts the flag from a vector conversion operator, or returns if it does not contain any.
-
The function extracts the flag from a vector conversion operator, or returns if it does not contain any.
2.4.10. Expressions
Function bodies, initialization values for globals, elements and offsets of element segments, and offsets of data segments are given as expressions, which are sequences of instructions.
In some places, validation restricts expressions to be constant, which limits the set of allowable instructions.
2.5. Modules
WebAssembly programs are organized into modules, which are the unit of deployment, loading, and compilation. A module collects definitions for types, tags, and globals, memories, tables, functions. In addition, it can declare imports and exports and provide initialization in the form of data and element segments, or a start function.
Each of the lists — and thus the entire module — may be empty.
2.5.1. Indices
Definitions are referenced with zero-based indices. Each class of definition has its own index space, as distinguished by the following classes.
The index space for tags, globals, memories, tables, and functions includes respective imports declared in the same module. The indices of these imports precede the indices of other definitions in the same index space.
Data indices reference data segments and element indices reference element segments.
The index space for locals is only accessible inside a function and includes the parameters of that function, which precede the local variables.
Label indices reference structured control instructions inside an instruction sequence.
Each aggregate type provides an index space for its fields.
2.5.1.1. Conventions
-
The meta variable ranges over label indices.
-
The meta variables , range over indices in any of the other index spaces.
-
For every index space , the notation denotes the set of indices from that index space occurring free in . Sometimes this set is reinterpreted as the list of its elements.
Note
For example, if is , then , or equivalently, the set .
2.5.2. Types
The section of a module defines a list of recursive types, each consisting of a list of sub types referenced by individual type indices. All function, structure, or array types used in a module must be defined in this section.
2.5.4. Globals
The section of a module defines a list of global variables (or globals for short):
Each global stores a single value of the type specified in the global type. It also specifies whether a global is immutable or mutable. Moreover, each global is initialized with a value given by a constant initializer expression.
Globals are referenced through global indices, starting with the smallest index not referencing a global import.
2.5.5. Memories
The section of a module defines a list of linear memories (or memories for short) as described by their memory type:
A memory is a list of raw uninterpreted bytes. The minimum size in the limits of its memory type specifies the initial size of that memory, while its maximum, if present, restricts the size to which it can grow later. Both are in units of page size.
Memories can be initialized through data segments.
Memories are referenced through memory indices, starting with the smallest index not referencing a memory import. Most constructs implicitly reference memory index .
2.5.6. Tables
The section of a module defines a list of tables described by their table type:
A table is an array of opaque values of a particular reference type that is specified by the table type. Each table slot is initialized with a value given by a constant initializer expression. Tables can further be initialized through element segments.
The minimum size in the limits of the table type specifies the initial size of that table, while its maximum restricts the size to which it can grow later.
Tables are referenced through table indices, starting with the smallest index not referencing a table import. Most constructs implicitly reference table index .
2.5.7. Functions
The section of a module defines a list of functions with the following structure:
The type index of a function declares its signature by reference to a function type defined in the module. The parameters of the function are referenced through 0-based local indices in the function’s body; they are mutable.
The locals declare a list of mutable local variables and their types. These variables are referenced through local indices in the function’s body. The index of the first local is the smallest index not referencing a parameter.
A function’s expression is an instruction sequence that represents the body of the function. Upon termination it must produce a stack matching the function type’s result type.
Functions are referenced through function indices, starting with the smallest index not referencing a function import.
2.5.8. Data Segments
The section of a module defines a list of data segments, which can be used to initialize a range of memory from a static list of bytes.
Similar to element segments, data segments have a mode that identifies them as either active or passive. A passive data segment’s contents can be copied into a memory using the instruction. An active data segment copies its contents into a memory during instantiation, as specified by a memory index and a constant expression defining an offset into that memory.
Data segments are referenced through data indices.
2.5.9. Element Segments
The section of a module defines a list of element segments, which can be used to initialize a subrange of a table from a static list of elements.
Each element segment defines a reference type and a corresponding list of constant element expressions.
Element segments have a mode that identifies them as either active, passive, or declarative. A passive element segment’s elements can be copied to a table using the instruction. An active element segment copies its elements into a table during instantiation, as specified by a table index and a constant expression defining an offset into that table. A declarative element segment is not available at runtime but merely serves to forward-declare references that are formed in code with instructions like . The offset is given by another constant expression.
Element segments are referenced through element indices.
2.5.10. Start Function
The section of a module declares the function index of a start function that is automatically invoked when the module is instantiated, after tables and memories have been initialized.
Note
The start function is intended for initializing the state of a module. The module and its exports are not accessible externally before this initialization has completed.
2.5.11. Imports
The section of a module defines a set of imports that are required for instantiation.
Each import is labeled by a two-level name space, consisting of a module name and an item name for an entity within that module. Importable definitions are tags, globals, memories, tables, and functions. Each import is specified by a respective external type that a definition provided during instantiation is required to match.
Every import defines an index in the respective index space. In each index space, the indices of imports go before the first index of any definition contained in the module itself.
Note
Unlike export names, import names are not necessarily unique. It is possible to import the same module/item name pair multiple times; such imports may even have different type descriptions, including different kinds of entities. A module with such imports can still be instantiated depending on the specifics of how an embedder allows resolving and supplying imports. However, embedders are not required to support such overloading, and a WebAssembly module itself cannot implement an overloaded name.
2.5.12. Exports
The section of a module defines a set of exports that become accessible to the host environment once the module has been instantiated.
Each export is labeled by a unique name. Exportable definitions are tags, globals, memories, tables, and functions, which are referenced through a respective index.
2.5.12.1. Conventions
The following auxiliary notation is defined for sequences of exports, filtering out indices of a specific kind in an order-preserving fashion:
3. Validation
3.1. Conventions
Validation checks that a WebAssembly module is well-formed. Only valid modules can be instantiated.
Validity is defined by a type system over the abstract syntax of a module and its contents. For each piece of abstract syntax, there is a typing rule that specifies the constraints that apply to it. All rules are given in two equivalent forms:
-
In prose, describing the meaning in intuitive form.
-
In formal notation, describing the rule in mathematical form. [1]
Note
The prose and formal rules are equivalent, so that understanding of the formal notation is not required to read this specification. The formalism offers a more concise description in notation that is used widely in programming languages semantics and is readily amenable to mathematical proof.
In both cases, the rules are formulated in a declarative manner. That is, they only formulate the constraints, they do not define an algorithm. The skeleton of a sound and complete algorithm for type-checking instruction sequences according to this specification is provided in the appendix.
3.1.1. Types
To define the semantics, the definition of some sorts of types is extended to include additional forms. By virtue of not being representable in either the binary format or the text format, these forms cannot be used in a program; they only occur during validation or execution.
The unique value type is a bottom type that matches all value types. Similarly, is also used as a bottom type of all heap types.
Note
No validation rule uses bottom types explicitly, but various rules can pick any value or heap type, including bottom. This ensures the existence of principal types, and thus a validation algorithm without back tracking.
A type use can consist directly of a defined type. This occurs as the result of substituting a type index with its definition.
A type use may also be a recursive type index. Such an index refers to the -th component of a surrounding recursive type. It occurs as the result of rolling up the definition of a recursive type.
Both extensions affect occurrences of type uses in concrete heap types, in sub types and in instructions.
A type of any form is closed when it does not contain a heap type that is a type index or a recursive type index without a surrounding recursive type, i.e., all type indices have been substituted with their defined type and all free recursive type indices have been unrolled.
Note
It is an invariant of the semantics that sub types occur only in one of two forms: either as “syntactic” types as in a source module, where all supertypes are type indices, or as “semantic” types, where all supertypes are resolved to either defined types or recursive type indices.
Recursive type indices are local to a recursive type. They are distinguished from regular type indices and represented such that two closed types are syntactically equal if and only if they have the same recursive structure.
3.1.1.1. Convention
-
The difference between two reference types is defined as follows:
Note
This definition computes an approximation of the reference type that is inhabited by all values from except those from . Since the type system does not have general union types, the defnition only affects the presence of null and cannot express the absence of other values.
3.1.2. Defined Types
Defined types denote the individual types defined in a module. Each such type is represented as a projection from the recursive type group it originates from, indexed by its position in that group.
Defined types do not occur in the binary or text format, but are formed by rolling up the recursive types defined in a module.
Note
It is an invariant of the semantics that all recursive types occurring in defined types are rolled up.
3.1.2.1. Conventions
-
denotes the parallel substitution of type indices with corresponding defined types in type , provided .
-
denotes the parallel substitution of recursive type indices with defined types in type , provided . This substitution does not proceed under recursive types, since they are considered local binders for all recursive type indices.
-
is shorthand for the substitution , where .
Note
All recursive types formed by the semantics are closed with respect to recursive type indices that occur inside them. Hence, substitution of recursive type indices never needs to modify the bodies of recursive types. In addition, all types used for substitution are closed with respect to recursive type indices, such that name capture of recursive type indices cannot occur.
3.1.3. Rolling and Unrolling
In order to allow comparing recursive types for equivalence, their representation is changed such that all type indices internal to the same recursive type are replaced by recursive type indices.
Note
This representation is independent of the type index space, so that it is meaningful across module boundaries. Moreover, this representation ensures that types with equivalent recursive structure are also syntactically equal, hence allowing a simple equality check on (closed) types. It gives rise to an iso-recursive interpretation of types.
The representation change is performed by two auxiliary operations on the syntax of recursive types:
-
Rolling up a recursive type substitutes its internal type indices with corresponding recursive type indices.
-
Unrolling a recursive type substitutes its recursive type indices with the corresponding defined types.
These operations are extended to defined types and defined as follows:
In addition, the following auxiliary relation denotes the expansion of a defined type or type use:
3.1.4. Instruction Types
Instruction types classify the behaviour of instructions or instruction sequences, by describing how they manipulate the operand stack and the initialization status of locals:
An instruction type describes the required input stack with argument values of types that an instruction pops off and the provided output stack with result values of types that it pushes back. Moreover, it enumerates the indices of locals that have been set by the instruction or sequence.
Note
Instruction types are only used for validation, they do not occur in programs.
3.1.5. Local Types
Local types classify locals, by describing their value type as well as their initialization status:
Note
Local types are only used for validation, they do not occur in programs.
3.1.6. Contexts
Validity of an individual definition is specified relative to a context, which collects relevant information about the surrounding module and the definitions in scope:
-
Types: the list of types defined in the current module.
-
Recursive Types: the list of sub types in the current group of recursive types.
-
Functions: the list of functions declared in the current module, represented by a defined type that expands to their function type.
-
Tables: the list of tables declared in the current module, represented by their table type.
-
Memories: the list of memories declared in the current module, represented by their memory type.
-
Globals: the list of globals declared in the current module, represented by their global type.
-
Tags: the list of tags declared in the current module, represented by their tag type.
-
Element Segments: the list of element segments declared in the current module, represented by the elements’ reference type.
-
Data Segments: the list of data segments declared in the current module, each represented by an entry.
-
Locals: the list of locals declared in the current function (including parameters), represented by their local type.
-
Labels: the stack of labels accessible from the current position, represented by their result type.
-
Return: the return type of the current function, represented as an optional result type that is absent when no return is allowed, as in free-standing expressions.
-
References: the list of function indices that occur in the module outside functions and can hence be used to form references inside them.
In other words, a context contains a sequence of suitable types for each index space, describing each defined entry in that space. Locals, labels and return type are only used for validating instructions in function bodies, and are left empty elsewhere. The label stack is the only part of the context that changes as validation of an instruction sequence proceeds.
More concretely, contexts are defined as records with abstract syntax:
3.1.6.1. Convention
A type of any shape can be closed to bring it into closed form relative to a context it is valid in, by substituting each type index occurring in it with its own corresponding defined type , after first closing the types in themselves.
Note
Free type indices referring to types within the same recursive type are handled separately by rolling up recursive types before closing them.
3.1.7. Prose Notation
Validation is specified by stylised rules for each relevant part of the abstract syntax. The rules not only state constraints defining when a phrase is valid, they also classify it with a type. The following conventions are adopted in stating these rules.
-
A phrase is said to be “valid with type ” if and only if all constraints expressed by the respective rules are met. The form of depends on the syntactic class of .
Note
For example, if is a function, then is a defined function type; for an that is a global, is a global type; and so on.
-
The rules implicitly assume a given context .
-
In some places, this context is locally extended to a context with additional entries. The formulation “Under context , … statement …” is adopted to express that the following statement must apply under the assumptions embodied in the extended context.
3.1.8. Formal Notation
Note
This section gives a brief explanation of the notation for specifying typing rules formally. For the interested reader, a more thorough introduction can be found in respective text books. [2]
The proposition that a phrase has a respective type is written . In general, however, typing is dependent on a context . To express this explicitly, the complete form is a judgement , which says that holds under the assumptions encoded in .
The formal typing rules use a standard approach for specifying type systems, rendering them into deduction rules. Every rule has the following general form:
Such a rule is read as a big implication: if all premises hold, then the conclusion holds. Some rules have no premises; they are axioms whose conclusion holds unconditionally. The conclusion always is a judgment , and there usually is one respective rule for each relevant construct of the abstract syntax.
Note
For example, the typing rule for the instruction can be given as an axiom:
The instruction is always valid with type (saying that it consumes two values and produces one), independent of any side conditions.
An instruction like can be typed as follows:
Here, the premise enforces that the immediate global index exists in the context. The instruction produces a value of its respective type (and does not consume any values). If does not exist then the premise does not hold, and the instruction is ill-typed.
Finally, a structured instruction requires a recursive rule, where the premise is itself a typing judgement:
A instruction is only valid when the instruction sequence in its body is. Moreover, the result type must match the block’s annotation . If so, then the instruction has the same type as the body. Inside the body an additional label of the corresponding result type is available, which is expressed by extending the context with the additional label information for the premise.
The semantics is derived from the following article: Andreas Haas, Andreas Rossberg, Derek Schuff, Ben Titzer, Dan Gohman, Luke Wagner, Alon Zakai, JF Bastien, Michael Holman. Bringing the Web up to Speed with WebAssembly. Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2017). ACM 2017.
For example: Benjamin Pierce. Types and Programming Languages. The MIT Press 2002
3.2. Types
Simple types, such as number types are universally valid. However, restrictions apply to most other types, such as reference types, function types, as well as the limits of table types and memory types, which must be checked during validation.
Moreover, block types are converted to instruction types for ease of processing.
3.2.1. Number Types
The number type is always valid.
3.2.2. Vector Types
The vector type is always valid.
3.2.3. Type Uses
The type exists.
3.2.4. Heap Types
The heap type is always valid.
3.2.5. Reference Types
The reference type is valid if:
3.2.6. Value Types
The value type is valid if:
Either:
The value type is of the form .
The number type is valid.
Or:
The value type is of the form .
The vector type is valid.
Or:
The value type is of the form .
The reference type is valid.
Or:
The value type is of the form .
3.2.7. Result Types
The result type is valid if:
For all in :
The value type is valid.
3.2.8. Block Types
Block types may be expressed in one of two forms, both of which are converted to instruction types by the following rules.
The block type is valid as the instruction type if:
The block type is valid as the instruction type if:
If is defined, then:
The value type is valid.
3.2.9. Instruction Types
The instruction type is valid if:
The result type is valid.
The result type is valid.
For all in :
The local exists.
3.2.10. Composite Types
The composite type is valid if:
For all in :
The field type is valid.
The composite type is valid if:
The field type is valid.
The composite type is valid if:
The result type is valid.
The result type is valid.
The field type is valid if:
The storage type is valid.
The packed type is always valid.
3.2.11. Recursive Types
Recursive types are validated with respect to the first type index defined by the recursive group.
3.2.11.1.
The recursive type is valid for the type index if:
Either:
The sub type sequence is empty.
Or:
The sub type sequence is of the form .
The recursive type is valid for the type index .
3.2.11.2.
The sub type is valid for the type index if:
The length of is less than or equal to .
For all in :
is the concatenation of all such .
The composite type is valid.
For all in :
The composite type matches the composite type .
Note
The side condition on the index ensures that a declared supertype is a previously defined types, preventing cyclic subtype hierarchies.
Future versions of WebAssembly may allow more than one supertype.
3.2.12. Limits
Limits must have meaningful bounds that are within a given range.
The limits range is valid within if:
is less than or equal to .
If is defined, then:
is less than or equal to .
is less than or equal to .
3.2.13. Tag Types
3.2.14. Global Types
The global type is valid if:
The value type is valid.
3.2.15. Memory Types
The memory type is valid if:
The limits range is valid within .
3.2.16. Table Types
The table type is valid if:
The limits range is valid within .
The reference type is valid.
3.2.17. External Types
The external type is valid if:
The external type is valid if:
The global type is valid.
The external type is valid if:
The memory type is valid.
The external type is valid if:
The table type is valid.
The external type is valid if:
3.3. Matching
On most types, a notion of subtyping is defined that is applicable in validation rules, during module instantiation when checking the types of imports, or during execution, when performing casts.
3.3.1. Number Types
The number type matches only itself.
3.3.2. Vector Types
The vector type matches only itself.
3.3.3. Heap Types
The heap type matches the heap type if:
Either:
The heap type is of the form .
Or:
Or:
Or:
Or:
Or:
Or:
Or:
Or:
Or:
The heap type is of the form .
The heap type is of the form .
The defined type matches the defined type .
Or:
Or:
Or:
The heap type is of the form .
The length of is greater than .
The heap type is of the form .
The recursive type exists.
The recursive type is of the form .
Or:
Or:
Or:
Or:
Or:
The heap type is of the form .
3.3.4. Reference Types
The reference type matches the reference type if:
3.3.5. Value Types
The value type matches the value type if:
Either:
The value type is of the form .
The value type is of the form .
The number type matches the number type .
Or:
The value type is of the form .
The value type is of the form .
The vector type matches the vector type .
Or:
The value type is of the form .
The value type is of the form .
The reference type matches the reference type .
Or:
The value type is of the form .
3.3.6. Result Types
Subtyping is lifted to result types in a pointwise manner.
The result type matches the result type if:
For all in , and corresponding in :
The value type matches the value type .
3.3.7. Instruction Types
Subtyping is further lifted to instruction types.
The instruction type matches the instruction type if:
The result type matches the result type .
The result type matches the result type .
The local index sequence is of the form .
For all in :
Note
Instruction types are contravariant in their input and covariant in their output. Moreover, the supertype may ignore variables from the init set . It may also add variables to the init set, provided these are already set in the context, i.e., are vacuously initialized.
3.3.8. Composite Types
The composite type matches the composite type if:
Either:
The composite type is of the form .
The composite type is of the form .
For all in , and corresponding in :
The field type matches the field type .
Or:
The composite type is of the form .
The composite type is of the form .
The field type matches the field type .
Or:
The composite type is of the form .
The composite type is of the form .
The result type matches the result type .
The result type matches the result type .
3.3.9. Field Types
The field type matches the field type if:
The storage type matches the storage type .
Either:
is absent.
is absent.
Or:
is of the form .
is of the form .
The storage type matches the storage type .
The storage type matches the storage type if:
Either:
The storage type is of the form .
The storage type is of the form .
The value type matches the value type .
Or:
The storage type is of the form .
The storage type is of the form .
The packed type matches the packed type .
The packed type matches only itself.
3.3.10. Defined Types
The defined type matches the defined type if:
Either:
The defined type is of the form .
Or:
Note
Note that there is no explicit definition of type equivalence, since it coincides with syntactic equality, as used in the premise of the former rule above.
3.3.11. Limits
The limits range matches the limits range if:
is greater than or equal to .
is less than or equal to .
3.3.12. Tag Types
The tag type matches the tag type if:
The defined type matches the defined type .
The defined type matches the defined type .
Note
Although the conclusion of this rule looks identical to its premise, they in fact describe different relations: the premise invokes subtyping on defined types, while the conclusion defines it on tag types that happen to be expressed as defined types.
3.3.13. Global Types
The global type matches the global type if:
The value type matches the value type .
Either:
is absent.
is absent.
Or:
is of the form .
is of the form .
The value type matches the value type .
3.3.14. Memory Types
The memory type matches the memory type if:
The limits range matches the limits range .
3.3.15. Table Types
The table type matches the table type if:
The limits range matches the limits range .
The reference type matches the reference type .
The reference type matches the reference type .
3.3.16. External Types
The external type matches the external type if:
The external type matches the external type if:
The global type matches the global type .
The external type matches the external type if:
The memory type matches the memory type .
The external type matches the external type if:
The table type matches the table type .
The external type matches the external type if:
The defined type matches the defined type .
3.4. Instructions
Instructions are classified by instruction types that describe how they manipulate the operand stack and initialize locals: A type describes the required input stack with argument values of types that an instruction pops off and the provided output stack with result values of types that it pushes back. Moreover, it enumerates the indices of locals that have been set by the instruction. In most cases, this is empty.
Note
For example, the instruction has type , consuming two values and producing one. The instruction has type , provided is the type declared for the local .
Typing extends to instruction sequences . Such a sequence has an instruction type if the accumulative effect of executing the instructions is consuming values of types off the operand stack, pushing new values of types , and setting all locals .
For some instructions, the typing rules do not fully constrain the type, and therefore allow for multiple types. Such instructions are called polymorphic. Two degrees of polymorphism can be distinguished:
-
value-polymorphic: the value type of one or several individual operands is unconstrained. That is the case for all parametric instructions like and .
-
stack-polymorphic: the entire (or most of the) instruction type of the instruction is unconstrained. That is the case for all control instructions that perform an unconditional control transfer, such as , , or .
In both cases, the unconstrained types or type sequences can be chosen arbitrarily, as long as they meet the constraints imposed for the surrounding parts of the program.
Note
For example, the instruction is valid with type , for any possible number type . Consequently, both instruction sequences
and
are valid, with in the typing of being instantiated to or , respectively.
The instruction is stack-polymorphic, and hence valid with type for any possible sequences of value types and . Consequently,
is valid by assuming type for the instruction. In contrast,
is invalid, because there is no possible type to pick for the instruction that would make the sequence well-typed.
The Appendix describes a type checking algorithm that efficiently implements validation of instruction sequences as prescribed by the rules given here.
3.4.1. Parametric Instructions
3.4.1.1.
The instruction is valid with the instruction type .
3.4.1.2.
The instruction is valid with the instruction type if:
The instruction type is valid.
Note
The instruction is stack-polymorphic.
3.4.1.3.
The instruction is valid with the instruction type if:
The value type is valid.
Note
Both and without annotation are value-polymorphic instructions.
3.4.1.4.
The instruction is valid with the instruction type if:
The value type is valid.
Either:
The value type sequence is of the form .
Or:
The value type sequence is absent.
The value type matches the value type .
The value type is of the form or is of the form .
Note
In future versions of WebAssembly, may allow more than one value per choice.
3.4.2. Control Instructions
3.4.2.1.
The instruction is valid with the instruction type if:
The block type is valid as the instruction type .
Let be the same context as , but with the result type sequence prepended to the field .
Under the context , the instruction sequence is valid with the instruction type .
Note
The notation inserts the new label type at index , shifting all others. The same applies to all other block instructions.
3.4.2.2.
The instruction is valid with the instruction type if:
The block type is valid as the instruction type .
Let be the same context as , but with the result type sequence prepended to the field .
Under the context , the instruction sequence is valid with the instruction type .
3.4.2.3.
The instruction is valid with the instruction type if:
The block type is valid as the instruction type .
Let be the same context as , but with the result type sequence prepended to the field .
Under the context , the instruction sequence is valid with the instruction type .
Under the context , the instruction sequence is valid with the instruction type .
3.4.2.4.
The instruction is valid with the instruction type if:
The label exists.
The label is of the form .
The instruction type is valid.
Note
The label index space in the context contains the most recent label first, so that performs a relative lookup as expected. This applies to other branch instructions as well.
The instruction is stack-polymorphic.
3.4.2.5.
The instruction is valid with the instruction type if:
3.4.2.6.
The instruction is valid with the instruction type if:
For all in :
The label exists.
The result type matches the label .
The label exists.
The result type matches the label .
The instruction type is valid.
Note
The instruction is stack-polymorphic.
Furthermore, the result type is also chosen non-deterministically in this rule. Although it may seem necessary to compute as the greatest lower bound of all label types in practice, a simple sequential algorithm does not require this.
3.4.2.7.
The instruction is valid with the instruction type if:
3.4.2.8.
The instruction is valid with the instruction type if:
3.4.2.9.
The instruction is valid with the instruction type if:
The label exists.
The label is of the form .
The reference type is valid.
The reference type is valid.
The reference type matches the reference type .
The reference type matches the reference type .
The reference type is .
3.4.2.10.
The instruction is valid with the instruction type if:
The label exists.
The label is of the form .
The reference type is valid.
The reference type is valid.
The reference type matches the reference type .
The reference type matches the reference type .
3.4.2.11.
The instruction is valid with the instruction type if:
3.4.2.12.
The instruction is valid with the instruction type if:
3.4.2.13.
The instruction is valid with the instruction type if:
The table exists.
The table is of the form .
The reference type matches the reference type .
The type exists.
The expansion of is .
3.4.2.14.
The instruction is valid with the instruction type if:
The result type is of the form .
The instruction type is valid.
Note
The instruction is stack-polymorphic.
is absent (set to ) when validating an expression that is not a function body. This differs from it being set to the empty result type , which is the case for functions not returning anything.
3.4.2.15.
The instruction is valid with the instruction type if:
The function exists.
The expansion of is .
The result type is of the form .
The result type matches the result type .
The instruction type is valid.
Note
The instruction is stack-polymorphic.
3.4.2.16.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The result type is of the form .
The result type matches the result type .
The instruction type is valid.
Note
The instruction is stack-polymorphic.
3.4.2.17.
The instruction is valid with the instruction type if:
The table exists.
The table is of the form .
The reference type matches the reference type .
The type exists.
The expansion of is .
The result type is of the form .
The result type matches the result type .
The instruction type is valid.
Note
The instruction is stack-polymorphic.
3.4.2.18.
The instruction is valid with the instruction type if:
The tag exists.
The expansion of is .
The instruction type is valid.
Note
The instruction is stack-polymorphic.
3.4.2.19.
The instruction is valid with the instruction type if:
The instruction type is valid.
Note
The instruction is stack-polymorphic.
3.4.2.20.
The instruction is valid with the instruction type if:
The block type is valid as the instruction type .
Let be the same context as , but with the result type sequence prepended to the field .
Under the context , the instruction sequence is valid with the instruction type .
For all in :
The catch clause is valid.
3.4.2.21.
The catch clause is valid if:
3.4.2.22.
The catch clause is valid if:
3.4.2.23.
The catch clause is valid if:
The label exists.
The result type matches the label .
3.4.2.24.
The catch clause is valid if:
The label exists.
The result type matches the label .
3.4.3. Variable Instructions
3.4.3.1.
The instruction is valid with the instruction type if:
3.4.3.2.
The instruction is valid with the instruction type if:
3.4.3.3.
The instruction is valid with the instruction type if:
3.4.3.4.
The instruction is valid with the instruction type if:
3.4.3.5.
The instruction is valid with the instruction type if:
3.4.4. Table Instructions
3.4.4.1.
The instruction is valid with the instruction type if:
3.4.4.2.
The instruction is valid with the instruction type if:
3.4.4.3.
The instruction is valid with the instruction type if:
3.4.4.4.
The instruction is valid with the instruction type if:
3.4.4.5.
The instruction is valid with the instruction type if:
3.4.4.6.
The instruction is valid with the instruction type if:
The table exists.
The table is of the form .
The table exists.
The table is of the form .
The reference type matches the reference type .
The address type is .
3.4.4.7.
The instruction is valid with the instruction type if:
The table exists.
The table is of the form .
The element segment exists.
The element segment is of the form .
The reference type matches the reference type .
3.4.4.8.
The instruction is valid with the instruction type if:
The element segment exists.
3.4.5. Memory Instructions
3.4.5.1.
The instruction is valid with the instruction type if:
3.4.5.2.
The instruction is valid with the instruction type if:
3.4.5.3.
The instruction is valid with the instruction type if:
3.4.5.4.
The instruction is valid with the instruction type if:
3.4.5.5.
The instruction is valid with the instruction type if:
3.4.5.6.
The instruction is valid with the instruction type if:
3.4.5.7.
The instruction is valid with the instruction type if:
3.4.5.8.
The instruction is valid with the instruction type if:
3.4.5.9.
The instruction is valid with the instruction type if:
3.4.5.10.
The instruction is valid with the instruction type if:
3.4.5.11.
The instruction is valid with the instruction type if:
3.4.5.12.
The instruction is valid with the instruction type if:
3.4.5.13.
The instruction is valid with the instruction type if:
3.4.5.14.
The instruction is valid with the instruction type if:
3.4.5.15.
The instruction is valid with the instruction type if:
The memory exists.
The memory is of the form .
The memory exists.
The memory is of the form .
The address type is .
3.4.5.16.
The instruction is valid with the instruction type if:
The memory exists.
The memory is of the form .
The data segment exists.
The data segment is of the form .
3.4.5.17.
The instruction is valid with the instruction type if:
The data segment exists.
The data segment is of the form .
3.4.6. Reference Instructions
3.4.6.1.
The instruction is valid with the instruction type if:
3.4.6.2.
The instruction is valid with the instruction type if:
3.4.6.3.
The instruction is valid with the instruction type if:
3.4.6.4.
The instruction is valid with the instruction type if:
3.4.6.5.
The instruction is valid with the instruction type .
3.4.6.6.
The instruction is valid with the instruction type if:
The reference type is valid.
The reference type is valid.
The reference type matches the reference type .
Note
The liberty to pick a supertype allows typing the instruction with the least precise super type of as input, that is, the top type in the corresponding heap subtyping hierarchy.
3.4.6.7.
The instruction is valid with the instruction type if:
The reference type is valid.
The reference type is valid.
The reference type matches the reference type .
Note
The liberty to pick a supertype allows typing the instruction with the least precise super type of as input, that is, the top type in the corresponding heap subtyping hierarchy.
3.4.7. Aggregate Reference Instructions
3.4.7.1.
The instruction is valid with the instruction type if:
3.4.7.2.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
For all in :
A default value for is defined.
3.4.7.3.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The length of is greater than .
The field type is of the form .
The signedness is absent if and only if is a packed type.
The value type is .
3.4.7.4.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The length of is greater than .
The field type is of the form .
The value type is .
3.4.7.5.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The value type is .
3.4.7.6.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
A default value for is defined.
3.4.7.7.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The value type is .
3.4.7.8.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The element segment exists.
The element segment matches the reference type .
3.4.7.9.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The value type is of the form or is of the form .
The data segment exists.
The data segment is of the form .
3.4.7.10.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The signedness is absent if and only if is a packed type.
The value type is .
3.4.7.11.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The value type is .
3.4.7.12.
The instruction is valid with the instruction type .
3.4.7.13.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The value type is .
3.4.7.14.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The type exists.
The expansion of is .
The storage type matches the storage type .
3.4.7.15.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The element segment exists.
The element segment matches the storage type .
3.4.7.16.
The instruction is valid with the instruction type if:
The type exists.
The expansion of is .
The value type is of the form or is of the form .
The data segment exists.
The data segment is of the form .
3.4.8. Scalar Reference Instructions
3.4.8.1.
The instruction is valid with the instruction type .
3.4.8.2.
The instruction is valid with the instruction type .
3.4.9. External Reference Instructions
3.4.9.1.
The instruction is valid with the instruction type if:
is of the form .
3.4.9.2.
The instruction is valid with the instruction type if:
is of the form .
3.4.10. Numeric Instructions
3.4.10.1.
The instruction is valid with the instruction type .
3.4.10.2.
The instruction is valid with the instruction type .
3.4.10.3.
The instruction is valid with the instruction type .
3.4.10.4.
The instruction is valid with the instruction type .
3.4.10.5.
The instruction is valid with the instruction type .
3.4.10.6.
The instruction is valid with the instruction type .
3.4.11. Vector Instructions
Vector instructions can have a prefix to describe the shape of the operand. Packed numeric types, and , are not value types. An auxiliary function maps such packed type shapes to value types:
3.4.11.1.
The instruction is valid with the instruction type .
3.4.11.2.
The instruction is valid with the instruction type .
3.4.11.3.
The instruction is valid with the instruction type .
3.4.11.4.
The instruction is valid with the instruction type .
3.4.11.5.
The instruction is valid with the instruction type .
3.4.11.6.
The instruction is valid with the instruction type .
3.4.11.7.
The instruction is valid with the instruction type .
3.4.11.8.
The instruction is valid with the instruction type .
3.4.11.9.
The instruction is valid with the instruction type .
3.4.11.10.
The instruction is valid with the instruction type .
3.4.11.11.
The instruction is valid with the instruction type .
3.4.11.12.
The instruction is valid with the instruction type .
3.4.11.13.
The instruction is valid with the instruction type .
3.4.11.14.
The instruction is valid with the instruction type if:
For all in :
The lane index is less than .
3.4.11.15.
The instruction is valid with the instruction type if:
The number type is .
3.4.11.16.
The instruction is valid with the instruction type if:
The lane index is less than .
The number type is .
3.4.11.17.
The instruction is valid with the instruction type if:
The lane index is less than .
The number type is .
3.4.11.18.
The instruction is valid with the instruction type .
3.4.11.19.
The instruction is valid with the instruction type .
3.4.11.20.
The instruction is valid with the instruction type .
3.4.11.21.
The instruction is valid with the instruction type .
3.4.11.22.
The instruction is valid with the instruction type .
3.4.12. Instruction Sequences
Typing of instruction sequences is defined recursively.
3.4.12.1. Empty Instruction Sequence:
The instruction sequence is valid with the instruction type if:
Either:
The instruction sequence is empty.
The instruction type is of the form .
Or:
The instruction sequence is of the form .
The instruction type is of the form .
The instruction is valid with the instruction type .
For all in :
Under the context with the local types of updated to , the instruction sequence is valid with the instruction type .
Or:
The instruction sequence is valid with the instruction type .
The instruction type matches the instruction type .
The instruction type is valid.
Or:
The instruction type is of the form .
The instruction sequence is valid with the instruction type .
The result type is valid.
Note
In combination with the previous rule, subsumption allows to compose instructions whose types would not directly fit otherwise. For example, consider the instruction sequence
To type this sequence, its subsequence needs to be valid with an intermediate type. But the direct type of is , not matching the two inputs expected by . The subsumption rule allows to weaken the type of to the supertype , such that it can be composed with and yields the intermediate type for the subsequence. That can in turn be composed with the first constant.
Furthermore, subsumption allows to drop init variables from the instruction type in a context where they are not needed, for example, at the end of the body of a block.
3.4.13. Expressions
Expressions are classified by result types .
The expression is valid with the result type if:
The instruction sequence is valid with the instruction type .
3.4.13.1. Constant Expressions
In a constant expression, all instructions must be constant.
is constant if:
For all in :
is constant.
is constant if:
Either:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
The value is of the form .
Or:
Or:
The value is of the form .
is contained in [; ].
is contained in [; ; ].
Note
Currently, constant expressions occurring in globals are further constrained in that contained instructions are only allowed to refer to imported or previously defined globals. Constant expressions occurring in tables may only have instructions that refer to imported globals. This is enforced in the validation rule for modules by constraining the context accordingly.
The definition of constant expression may be extended in future versions of WebAssembly.
3.5. Modules
Modules are valid when all the components they contain are valid. To verify this, most definitions are themselves classified with a suitable type.
3.5.1. Types
The sequence of types defined in a module is validated incrementally, yielding a sequence of defined types representing them individually.
The type definition is valid with the defined type sequence if:
The length of is equal to .
The defined type sequence is of the form .
Let be the same context as , but with the defined type sequence appended to the field .
Under the context , the recursive type is valid for the type index .
The type definition sequence is valid with the defined type sequence if:
Either:
The type definition sequence is empty.
The defined type sequence is empty.
Or:
The type definition sequence is of the form .
The defined type sequence is of the form .
The type definition is valid with the defined type sequence .
Let be the same context as , but with the defined type sequence appended to the field .
Under the context , the type definition sequence is valid with the defined type sequence .
3.5.3. Globals
Globals are classified by global types.
The global is valid with the global type if:
The global type is valid.
The global type is of the form .
The expression is valid with the value type .
is constant.
Sequences of globals are handled incrementally, such that each definition has access to previous definitions.
The global sequence is valid with the global type sequence if:
Either:
The global sequence is empty.
The global type sequence is empty.
Or:
The global sequence is of the form .
The global type sequence is of the form .
The global is valid with the global type .
Let be the same context as , but with the global type sequence appended to the field .
Under the context , the global sequence is valid with the global type sequence .
3.5.4. Memories
Memories are classified by memory types.
The memory is valid with the memory type if:
The memory type is valid.
3.5.5. Tables
Tables are classified by table types.
The table is valid with the table type if:
The table type is valid.
The table type is of the form .
The expression is valid with the value type .
is constant.
3.5.6. Functions
Functions are classified by defined types that expand to function types of the form .
The function is valid with the type if:
The type exists.
The expansion of is .
For all in :
The local is valid with the local type .
is the concatenation of all such .
Under the context with the field appended by and the field appended by and the field appended by , the expression is valid with the result type .
3.5.7. Locals
Locals are classified with local types.
The local is valid with the local type if:
Either:
The initialization status is of the form .
A default value for is defined.
Or:
The initialization status is of the form .
A default value for is not defined.
Note
For cases where both rules are applicable, the former yields the more permissable type.
3.5.8. Data Segments
Data segments are classified by the singleton data type, which merely expresses well-formedness.
The memory segment is valid if:
Either:
The data mode is of the form .
Or:
The data mode is of the form .
The memory exists.
The memory is of the form .
The expression is valid with the value type .
is constant.
3.5.9. Element Segments
Element segments are classified by their element type.
The table segment is valid with the element type if:
The reference type is valid.
For all in :
The expression is valid with the value type .
is constant.
The element mode is valid with the element type .
The element mode is valid with the element type if:
Either:
The element mode is of the form .
Or:
The element mode is of the form .
Or:
The element mode is of the form .
The table exists.
The table is of the form .
The reference type matches the reference type .
The expression is valid with the value type .
is constant.
3.5.10. Start Function
The start function is valid if:
3.5.11. Imports
Imports are classified by external types.
The import is valid with the external type if:
The external type is valid.
The external type is .
3.5.12. Exports
Exports are classified by their external type.
The export is valid with the name and the external type if:
The external index is valid with the external type .
3.5.12.1.
The external index is valid with the external type if:
3.5.12.2.
The external index is valid with the external type if:
3.5.12.3.
The external index is valid with the external type if:
3.5.12.4.
The external index is valid with the external type if:
3.5.12.5.
The external index is valid with the external type if:
3.5.13. Modules
Modules are classified by their mapping from the external types of their imports to those of their exports.
A module is entirely closed, that is, its components can only refer to definitions that appear in the module itself. Consequently, no initial context is required. Instead, the context for validation of the module’s content is constructed from the definitions in the module.
The module is valid with the module type if:
Under the context , the type definition sequence is valid with the defined type sequence .
For all in :
Under the context , the import is valid with the external type .
is the concatenation of all such .
For all in :
is the concatenation of all such .
Under the context , the global sequence is valid with the global type sequence .
For all in :
Under the context , the memory is valid with the memory type .
is the concatenation of all such .
For all in :
Under the context , the table is valid with the table type .
is the concatenation of all such .
For all in :
The function is valid with the defined type .
is the concatenation of all such .
For all in :
The memory segment is valid.
is the concatenation of all such .
For all in :
The table segment is valid with the element type .
is the concatenation of all such .
If is defined, then:
The start function is valid.
For all in :
The export is valid with the name and the external type .
is the concatenation of all such .
is the concatenation of all such .
is true.
The context is of the form with the field appended by and the field appended by and the field appended by and the field appended by and the field appended by and the field appended by .
The context is of the form .
The function index sequence is of the form .
The tag type sequence is of the form .
The global type sequence is of the form .
The memory type sequence is of the form .
The table type sequence is of the form .
The defined type sequence is of the form .
The module type is .
Note
All functions in a module are mutually recursive. Consequently, the definition of the context in this rule is recursive: it depends on the outcome of validation of the function, table, memory, and global definitions contained in the module, which itself depends on . However, this recursion is just a specification device. All types needed to construct can easily be determined from a simple pre-pass over the module that does not perform any actual validation.
Globals, however, are not recursive but evaluated sequentially, such that each constant expressions only has access to imported or previously defined globals.
4. Execution
4.1. Conventions
WebAssembly code is executed when instantiating a module or invoking an exported function on the resulting module instance.
Execution behavior is defined in terms of an abstract machine that models the program state. It includes a stack, which records operand values and control constructs, and an abstract store containing global state.
For each instruction, there is a rule that specifies the effect of its execution on the program state. Furthermore, there are rules describing the instantiation of a module. As with validation, all rules are given in two equivalent forms:
-
In prose, describing the execution in intuitive form.
-
In formal notation, describing the rule in mathematical form. [1]
Note
As with validation, the prose and formal rules are equivalent, so that understanding of the formal notation is not required to read this specification. The formalism offers a more concise description in notation that is used widely in programming languages semantics and is readily amenable to mathematical proof.
4.1.1. Prose Notation
Execution is specified by stylised, step-wise rules for each instruction of the abstract syntax. The following conventions are adopted in stating these rules.
-
The execution rules implicitly assume a given store .
-
The execution rules also assume the presence of an implicit stack that is modified by pushing or popping values, labels, and frames.
-
Certain rules require the stack to contain at least one frame. The most recent frame is referred to as the current frame.
-
Both the store and the current frame are mutated by replacing some of their components. Such replacement is assumed to apply globally.
-
The execution of an instruction may trap, in which case the entire computation is aborted and no further modifications to the store are performed by it. (Other computations can still be initiated afterwards.)
-
The execution of an instruction may also end in a jump to a designated target, which defines the next instruction to execute.
-
Execution can enter and exit instruction sequences that form blocks.
-
Instruction sequences are implicitly executed in order, unless a trap, jump, or exception occurs.
-
In various places the rules contain assertions expressing crucial invariants about the program state.
4.1.2. Formal Notation
Note
This section gives a brief explanation of the notation for specifying execution formally. For the interested reader, a more thorough introduction can be found in respective text books. [2]
The formal execution rules use a standard approach for specifying operational semantics, rendering them into reduction rules. Every rule has the following general form:
A configuration is a syntactic description of a program state. Each rule specifies one step of execution. As long as there is at most one reduction rule applicable to a given configuration, reduction – and thereby execution – is deterministic. WebAssembly has only very few exceptions to this, which are noted explicitly in this specification.
For WebAssembly, a configuration typically is a tuple consisting of the current store , the call frame of the current function, and the sequence of instructions that is to be executed. (A more precise definition is given later.)
To avoid unnecessary clutter, the store and the frame are often combined into a state , which is a pair . Moreover, is omitted from reduction rules that do not touch them.
There is no separate representation of the stack. Instead, it is conveniently represented as part of the configuration’s instruction sequence. In particular, values are defined to coincide with and instructions, and a sequence of such instructions can be interpreted as an operand “stack” that grows to the right.
Note
For example, the reduction rule for the instruction can be given as follows:
Per this rule, two instructions and the instruction itself are removed from the instruction stream and replaced with one new instruction. This can be interpreted as popping two values off the stack and pushing the result.
When no result is produced, an instruction reduces to the empty sequence:
Labels and frames are similarly defined to be part of an instruction sequence.
The order of reduction is determined by the details of the reduction rules. Usually, the left-most instruction that is not a constant will be the subject of the next reduction step.
Reduction terminates when no more reduction rules are applicable. Soundness of the WebAssembly type system guarantees that this is only the case when the original instruction sequence has either been reduced to a sequence of value instructions, which can be interpreted as the values of the resulting operand stack, or if an exception or trap occurred.
Note
For example, the following instruction sequence,
terminates after three steps:
where and and .
The semantics is derived from the following article: Andreas Haas, Andreas Rossberg, Derek Schuff, Ben Titzer, Dan Gohman, Luke Wagner, Alon Zakai, JF Bastien, Michael Holman. Bringing the Web up to Speed with WebAssembly. Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2017). ACM 2017.
For example: Benjamin Pierce. Types and Programming Languages. The MIT Press 2002
4.2. Runtime Structure
Store, stack, and other runtime structure forming the WebAssembly abstract machine, such as values or module instances, are made precise in terms of additional auxiliary syntax.
4.2.1. Values
WebAssembly computations manipulate values of either the four basic number types, i.e., integers and floating-point data of 32 or 64 bit width each, or vectors of 128 bit width, or of reference type.
In most places of the semantics, values of different types can occur. In order to avoid ambiguities, values are therefore represented with an abstract syntax that makes their type explicit. It is convenient to reuse the same notation as for the instructions and producing them.
References other than null are represented with additional administrative instructions. They either are scalar references, containing a 31-bit integer, structure references, pointing to a specific structure address, array references, pointing to a specific array address, function references, pointing to a specific function address, exception references, pointing to a specific exception address, or host references pointing to an uninterpreted form of host address defined by the embedder. Any of the aformentioned references can furthermore be wrapped up as an external reference.
Note
Future versions of WebAssembly may add additional forms of values.
Value types can have an associated default value; it is the respective value for number types, for vector types, and null for nullable reference types. For other references, no default value is defined, hence is an optional value .
4.2.1.1. Convention
-
The meta variable ranges over reference values where clear from context.
4.2.2. Results
A result is the outcome of a computation. It is either a sequence of values, a thrown exception, or a trap.
4.2.3. Store
The store represents all global state that can be manipulated by WebAssembly programs. It consists of the runtime representation of all instances of functions, tables, memories, globals, tags, element segments, data segments, and structures, arrays or exceptions that have been allocated during the life time of the abstract machine.
It is an invariant of the semantics that no element or data instance is addressed from anywhere else but the owning module instances.
Syntactically, the store is defined as a record listing the existing instances of each category:
Note
In practice, implementations may apply techniques like garbage collection or reference counting to remove objects from the store that are no longer referenced. However, such techniques are not semantically observable, and hence outside the scope of this specification.
4.2.3.1. Convention
-
The meta variable ranges over stores where clear from context.
4.2.4. Addresses
Function instances, table instances, memory instances, global instances, tag instances, element instances, data instances and structure, array or exception instances in the store are referenced with abstract addresses. These are simply indices into the respective store component. In addition, an embedder may supply an uninterpreted set of host addresses.
An embedder may assign identity to exported store objects corresponding to their addresses, even where this identity is not observable from within WebAssembly code itself (such as for function instances or immutable globals).
Note
Addresses are dynamic, globally unique references to runtime objects, in contrast to indices, which are static, module-local references to their original definitions. A memory address denotes the abstract address of a memory instance in the store, not an offset inside a memory instance.
There is no specific limit on the number of allocations of store objects, hence logical addresses can be arbitrarily large natural numbers.
4.2.4.1. Conventions
-
The notation denotes the set of addresses from address space occurring free in . We sometimes reinterpret this set as the list of its elements, without assuming any particular order.
4.2.5. External Addresses
An external address is the runtime address of an entity that can be imported or exported. It is an address denoting either a function instance, global instance, table instance, memory instance, or tag instance in the shared store.
4.2.6. Module Instances
A module instance is the runtime representation of a module. It is created by instantiating a module, and collects runtime representations of all entities that are imported, defined, or exported by the module.
Each component references runtime instances corresponding to respective declarations from the original module – whether imported or defined – in the order of their static indices. Function instances, table instances, memory instances, global instances, and tag instances are denoted by their respective addresses in the store.
It is an invariant of the semantics that all export instances in a given module instance have different names.
Note
All record fields except are to be considered private components of a module instance. They are not accessible to other modules, only to function instances originating from the same module.
4.2.7. Function Instances
A function instance is the runtime representation of a function. It effectively is a closure of the original function over the runtime module instance of its originating module. The module instance is used to resolve references to other definitions during execution of the function.
A host function is a function expressed outside WebAssembly but passed to a module as an import. The definition and behavior of host functions are outside the scope of this specification. For the purpose of this specification, it is assumed that when invoked, a host function behaves non-deterministically, but within certain constraints that ensure the integrity of the runtime.
4.2.8. Table Instances
A table instance is the runtime representation of a table. It records its type and holds a sequence of reference values.
Table elements can be mutated through table instructions, the execution of an active element segment, or by external means provided by the embedder.
It is an invariant of the semantics that all table elements have a type matching the element type of . It also is an invariant that the length of the element sequence never exceeds the maximum size of .
4.2.9. Memory Instances
A memory instance is the runtime representation of a linear memory. It records its type and holds a sequence of bytes.
The length of the sequence always is a multiple of the WebAssembly page size, which is defined to be the constant – abbreviated .
A memory’s bytes can be mutated through memory instructions, the execution of an active data segment, or by external means provided by the embedder.
It is an invariant of the semantics that the length of the byte sequence, divided by page size, never exceeds the maximum size of .
4.2.10. Global Instances
A global instance is the runtime representation of a global variable. It records its type and holds an individual value.
The value of mutable globals can be mutated through variable instructions or by external means provided by the embedder.
It is an invariant of the semantics that the value has a type matching the value type of .
4.2.11. Tag Instances
A tag instance is the runtime representation of a tag definition. It records the defined type of the tag.
4.2.12. Element Instances
An element instance is the runtime representation of an element segment. It holds a list of references and its type.
It is an invariant of the semantics that all elements of a segment have a type matching .
4.2.13. Data Instances
An data instance is the runtime representation of a data segment. It holds a list of bytes.
4.2.14. Export Instances
An export instance is the runtime representation of an export. It defines the export’s name and the associated external address.
4.2.14.1. Conventions
The following auxiliary functions are assumed on sequences of external addresses. They extract addresses of a specific kind in an order-preserving fashion:
-
extracts all function addresses from ,
-
extracts all table addresses from ,
-
extracts all memory addresses from ,
-
extracts all global addresses from ,
-
extracts all tag addresses from .
4.2.15. Aggregate Instances
A structure instance is the runtime representation of a heap object allocated from a structure type. Likewise, an array instance is the runtime representation of a heap object allocated from an array type. Both record their respective defined type and hold a list of the values of their fields.
4.2.15.1. Conventions
-
Conversion of a regular value to a field value is defined as follows:
-
The inverse conversion of a field value to a regular value is defined as follows:
4.2.16. Exception Instances
An exception instance is the runtime representation of an exception produced by a instruction. It holds the address of the respective tag and the argument values.
4.2.17. Stack
Besides the store, most instructions interact with an implicit stack. The stack contains the two kinds of entries:
-
Values: the operands of instructions.
-
Control Frames: currently active control flow structures.
The latter can in turn be one of the following:
-
Labels: active structured control instructions that can be targeted by branches.
-
(Call) Frames: the activation records of active function calls.
-
Handlers: active exception handlers.
Note
Where clear from context, call frame is abbreviated to just frame.
All these entries can occur on the stack in any order during the execution of a program. Stack entries are described by abstract syntax as follows.
Note
It is possible to model the WebAssembly semantics using separate stacks for operands, control constructs, and calls. However, because the stacks are interdependent, additional book keeping about associated stack heights would be required. For the purpose of this specification, an interleaved representation is simpler.
4.2.17.1. Values
Values are represented by themselves.
4.2.17.2. Labels
Labels carry an argument arity and their associated branch target, which is expressed syntactically as an instruction sequence:
Intuitively, is the continuation to execute when the branch is taken, in place of the original control construct.
Note
For example, a loop label has the form
When performing a branch to this label, this executes the loop, effectively restarting it from the beginning. Conversely, a simple block label has the form
When branching, the empty continuation ends the targeted block, such that execution can proceed with consecutive instructions.
4.2.17.3. Call Frames
Call frames carry the return arity of the respective function, hold the values of its locals (including arguments) in the order corresponding to their static local indices, and a reference to the function’s own module instance:
Locals may be uninitialized, in which case they are empty. Locals are mutated by respective variable instructions.
4.2.17.4. Exception Handlers
Exception handlers are installed by instructions and record the corresponding list of catch clauses:
The handlers on the stack are searched when an exception is thrown.
4.2.17.5. Conventions
-
The meta variable ranges over labels where clear from context.
-
The meta variable ranges over frame states where clear from context.
-
The meta variable ranges over exception handlers where clear from context.
-
The following auxiliary definition takes a block type and looks up the instruction type that it denotes in the current frame:
4.2.18. Administrative Instructions
Note
This section is only relevant for the formal notation.
In order to express the reduction of traps, calls, exception handling, and control instructions, the syntax of instructions is extended to include the following administrative instructions:
An address reference represents an allocated reference value of respective form “on the stack”.
The , , and instructions model labels, frames, and active exception handlers, respectively, “on the stack”. Moreover, the administrative syntax maintains the nesting structure of the original structured control instruction or function body and their instruction sequences.
The instruction represents the occurrence of a trap. Traps are bubbled up through nested instruction sequences, ultimately reducing the entire program to a single instruction, signalling abrupt termination.
Note
For example, the reduction rule for is:
if the block type denotes a function type , such that is the block’s result arity. This rule replaces the block with a label instruction, which can be interpreted as “pushing” the label on the stack. When its end is reached, i.e., the inner instruction sequence has been reduced to the empty sequence – or rather, a sequence of values representing the results – then the instruction is eliminated courtesy of its own reduction rule:
This can be interpreted as removing the label from the stack and only leaving the locally accumulated operand values. Validation guarantees that matches the number of resulting values at this point.
4.2.18.1. Configurations
A configuration describes the current computation. It consists of the computations’s state and the sequence of instructions left to execute. The state in turn consists of a global store and a current frame referring to the module instance in which the computation runs, i.e., where the current function originates from.
Note
The current version of WebAssembly is single-threaded, but configurations with multiple threads may be supported in the future.
4.3. Numerics
Numeric primitives are defined in a generic manner, by operators indexed over a bit width .
Some operators are non-deterministic, because they can return one of several possible results (such as different NaN values). Technically, each operator thus returns a set of allowed values. For convenience, deterministic results are expressed as plain values, which are assumed to be identified with a respective singleton set.
Some operators are partial, because they are not defined on certain inputs. Technically, an empty set of results is returned for these inputs.
In formal notation, each operator is defined by equational clauses that apply in decreasing order of precedence. That is, the first clause that is applicable to the given arguments defines the result. In some cases, similar clauses are combined into one by using the notation or . When several of these placeholders occur in a single clause, then they must be resolved consistently: either the upper sign is chosen for all of them or the lower sign.
Note
For example, the operator is defined as follows:
This definition is to be read as a shorthand for the following expansion of each clause into two separate ones:
Numeric operators are lifted to input sequences by applying the operator element-wise, returning a sequence of results. When there are multiple inputs, they must be of equal length.
Note
For example, the unary operator , when given a sequence of floating-point values, return a sequence of floating-point results:
The binary operator , when given two sequences of integers of the same length, , return a sequence of integer results:
Conventions:
-
The meta variable is used to range over single bits.
-
The meta variable is used to range over (signless) magnitudes of floating-point values, including and .
-
The meta variable is used to range over (signless) rational magnitudes, excluding or .
-
The notation denotes the inverse of a bijective function .
-
Truncation of rational values is written , with the usual mathematical definition:
-
Saturation of integers is written and . The arguments to these two functions range over arbitrary signed integers.
-
Unsigned saturation, clamps to between and :
-
Signed saturation, clamps to between and :
-
4.3.1. Representations
Numbers and numeric vectors have an underlying binary representation as a sequence of bits:
The first case of these applies to representations of both integer value types and packed types.
Each of these functions is a bijection, hence they are invertible.
4.3.1.1. Integers
Integers are represented as base two unsigned numbers:
Boolean operators like , , or are lifted to bit sequences of equal length by applying them pointwise.
4.3.1.2. Floating-Point
Floating-point values are represented in the respective binary format defined by [IEEE-754-2019] (Section 3.4):
where and .
4.3.1.3. Vectors
Numeric vectors of type have the same underlying representation as an . They can also be interpreted as a sequence of numeric values packed into a with a particular , provided that .
This function is a bijection on , hence it is invertible.
Numeric values can be packed into lanes of a specific lane type and vice versa:
4.3.1.4. Storage
When a number is stored into memory, it is converted into a sequence of bytes in little endian byte order:
Again these functions are invertible bijections.
4.3.2. Integer Operations
4.3.2.1. Sign Interpretation
Integer operators are defined on values. Operators that use a signed interpretation convert the value using the following definition, which takes the two’s complement when the value lies in the upper half of the value range (i.e., its most significant bit is ):
This function is bijective, and hence invertible.
4.3.2.2. Boolean Interpretation
The integer result of predicates – i.e., tests and relational operators – is defined with the help of the following auxiliary function producing the value or depending on a condition.
4.3.2.3.
-
Return the result of adding and modulo .
4.3.2.4.
-
Return the result of subtracting from modulo .
4.3.2.5.
-
Return the result of multiplying and modulo .
4.3.2.6.
-
If is , then the result is undefined.
-
Else, return the result of dividing by , truncated toward zero.
Note
This operator is partial.
4.3.2.7.
-
Let be the signed interpretation of .
-
Let be the signed interpretation of .
-
If is , then the result is undefined.
-
Else if divided by is , then the result is undefined.
-
Else, return the result of dividing by , truncated toward zero.
Note
This operator is partial. Besides division by , the result of is not representable as an -bit signed integer.
4.3.2.8.
-
If is , then the result is undefined.
-
Else, return the remainder of dividing by .
4.3.2.9.
-
Let be the signed interpretation of .
-
Let be the signed interpretation of .
-
If is , then the result is undefined.
-
Else, return the remainder of dividing by , with the sign of the dividend .
4.3.2.10.
-
Return the bitwise negation of .
4.3.2.11.
-
Return the bitwise reversal of .
4.3.2.12.
-
Return the bitwise conjunction of and .
4.3.2.13.
-
Return the bitwise conjunction of and the bitwise negation of .
4.3.2.14.
-
Return the bitwise disjunction of and .
4.3.2.15.
-
Return the bitwise exclusive disjunction of and .
4.3.2.16.
-
Let be modulo .
-
Return the result of shifting left by bits, modulo .
4.3.2.17.
-
Let be modulo .
-
Return the result of shifting right by bits, extended with bits.
4.3.2.18.
-
Let be modulo .
-
Return the result of shifting right by bits, extended with the most significant bit of the original value.
4.3.2.19.
-
Let be modulo .
-
Return the result of rotating left by bits.
4.3.2.20.
-
Let be modulo .
-
Return the result of rotating right by bits.
4.3.2.21.
-
Return the count of leading zero bits in ; all bits are considered leading zeros if is .
4.3.2.22.
-
Return the count of trailing zero bits in ; all bits are considered trailing zeros if is .
4.3.2.23.
-
Return the count of non-zero bits in .
4.3.2.24.
-
Return if is zero, otherwise.
4.3.2.25.
-
Return if is zero, otherwise.
4.3.2.26.
-
Return if equals , otherwise.
4.3.2.27.
-
Return if does not equal , otherwise.
4.3.2.28.
-
Return if is less than , otherwise.
4.3.2.29.
-
Let be the signed interpretation of .
-
Let be the signed interpretation of .
-
Return if is less than , otherwise.
4.3.2.30.
-
Return if is greater than , otherwise.
4.3.2.31.
-
Let be the signed interpretation of .
-
Let be the signed interpretation of .
-
Return if is greater than , otherwise.
4.3.2.32.
-
Return if is less than or equal to , otherwise.
4.3.2.33.
-
Let be the signed interpretation of .
-
Let be the signed interpretation of .
-
Return if is less than or equal to , otherwise.
4.3.2.34.
-
Return if is greater than or equal to , otherwise.
4.3.2.35.
-
Let be the signed interpretation of .
-
Let be the signed interpretation of .
-
Return if is greater than or equal to , otherwise.
4.3.2.36.
-
Let be the result of computing .
-
Return .
4.3.2.37.
-
Let be the bitwise conjunction of and .
-
Let be the bitwise negation of .
-
Let be the bitwise conjunction of and .
-
Return the bitwise disjunction of and .
4.3.2.38.
-
Let be the signed interpretation of .
-
If is greater than or equal to , then return .
-
Else return the negation of j, modulo .
4.3.2.39.
-
Return the result of negating , modulo .
4.3.2.40.
-
Return if is , return otherwise.
4.3.2.41.
-
Return if is , return otherwise.
4.3.2.42.
-
Return if is , return otherwise.
4.3.2.43.
-
Return if is , return otherwise.
4.3.2.44.
-
Let be the result of adding and .
-
Return .
4.3.2.45.
-
Let be the signed interpretation of
-
Let be the signed interpretation of
-
Let be the result of adding and .
-
Return the value whose signed interpretation is .
4.3.2.46.
-
Let be the result of subtracting from .
-
Return .
4.3.2.47.
-
Let be the signed interpretation of
-
Let be the signed interpretation of
-
Let be the result of subtracting from .
-
Return the value whose signed interpretation is .
4.3.2.48.
-
Let be the result of adding , , and .
-
Return the result of dividing by , truncated toward zero.
4.3.2.49.
-
Return the whose signed interpretation is the result of .
4.3.3. Floating-Point Operations
Floating-point arithmetic follows the [IEEE-754-2019] standard, with the following qualifications:
-
All operators use round-to-nearest ties-to-even, except where otherwise specified. Non-default directed rounding attributes are not supported.
-
Following the recommendation that operators propagate NaN payloads from their operands is permitted but not required.
-
All operators use “non-stop” mode, and floating-point exceptions are not otherwise observable. In particular, neither alternate floating-point exception handling attributes nor operators on status flags are supported. There is no observable difference between quiet and signalling NaNs.
Note
Some of these limitations may be lifted in future versions of WebAssembly.
4.3.3.1. Rounding
Rounding always is round-to-nearest ties-to-even, in correspondence with [IEEE-754-2019] (Section 4.3.1).
An exact floating-point number is a rational number that is exactly representable as a floating-point number of given bit width .
A limit number for a given floating-point bit width is a positive or negative number whose magnitude is the smallest power of that is not exactly representable as a floating-point number of width (that magnitude is for and for ).
A candidate number is either an exact floating-point number or a positive or negative limit number for the given bit width .
A candidate pair is a pair of candidate numbers, such that no candidate number exists that lies between the two.
A real number is converted to a floating-point value of bit width as follows:
-
If is , then return .
-
Else if is an exact floating-point number, then return .
-
Else if greater than or equal to the positive limit, then return .
-
Else if is less than or equal to the negative limit, then return .
-
Else if and are a candidate pair such that , then:
-
If , then let be .
-
Else if , then let be .
-
Else if and the significand of is even, then let be .
-
Else, let be .
-
-
If is , then:
-
If , then return .
-
Else, return .
-
-
Else if is a limit number, then:
-
If , then return .
-
Else, return .
-
-
Else, return .
where:
4.3.3.2. NaN Propagation
When the result of a floating-point operator other than , , or is a NaN, then its sign is non-deterministic and the payload is computed as follows:
-
If the payload of all NaN inputs to the operator is canonical (including the case that there are no NaN inputs), then the payload of the output is canonical as well.
-
Otherwise the payload is picked non-deterministically among all arithmetic NaNs; that is, its most significant bit is and all others are unspecified.
-
In the deterministic profile, however, a positive canonical NaNs is reliably produced in the latter case.
The non-deterministic result is expressed by the following auxiliary function producing a set of allowed outputs from a set of inputs:
4.3.3.3.
-
If either or is a NaN, then return an element of .
-
Else if both and are infinities of opposite signs, then return an element of .
-
Else if both and are infinities of equal sign, then return that infinity.
-
Else if either or is an infinity, then return that infinity.
-
Else if both and are zeroes of opposite sign, then return positive zero.
-
Else if both and are zeroes of equal sign, then return that zero.
-
Else if either or is a zero, then return the other operand.
-
Else if both and are values with the same magnitude but opposite signs, then return positive zero.
-
Else return the result of adding and , rounded to the nearest representable value.
4.3.3.4.
-
If either or is a NaN, then return an element of .
-
Else if both and are infinities of equal signs, then return an element of .
-
Else if both and are infinities of opposite sign, then return .
-
Else if is an infinity, then return that infinity.
-
Else if is an infinity, then return that infinity negated.
-
Else if both and are zeroes of equal sign, then return positive zero.
-
Else if both and are zeroes of opposite sign, then return .
-
Else if is a zero, then return .
-
Else if is a zero, then return negated.
-
Else if both and are the same value, then return positive zero.
-
Else return the result of subtracting from , rounded to the nearest representable value.
Note
Up to the non-determinism regarding NaNs, it always holds that .
4.3.3.5.
-
If either or is a NaN, then return an element of .
-
Else if one of and is a zero and the other an infinity, then return an element of .
-
Else if both and are infinities of equal sign, then return positive infinity.
-
Else if both and are infinities of opposite sign, then return negative infinity.
-
Else if either or is an infinity and the other a value with equal sign, then return positive infinity.
-
Else if either or is an infinity and the other a value with opposite sign, then return negative infinity.
-
Else if both and are zeroes of equal sign, then return positive zero.
-
Else if both and are zeroes of opposite sign, then return negative zero.
-
Else return the result of multiplying and , rounded to the nearest representable value.
4.3.3.6.
-
If either or is a NaN, then return an element of .
-
Else if both and are infinities, then return an element of .
-
Else if both and are zeroes, then return an element of .
-
Else if is an infinity and a value with equal sign, then return positive infinity.
-
Else if is an infinity and a value with opposite sign, then return negative infinity.
-
Else if is an infinity and a value with equal sign, then return positive zero.
-
Else if is an infinity and a value with opposite sign, then return negative zero.
-
Else if is a zero and a value with equal sign, then return positive zero.
-
Else if is a zero and a value with opposite sign, then return negative zero.
-
Else if is a zero and a value with equal sign, then return positive infinity.
-
Else if is a zero and a value with opposite sign, then return negative infinity.
-
Else return the result of dividing by , rounded to the nearest representable value.
4.3.3.7.
The function is the same as fusedMultiplyAdd defined by [IEEE-754-2019] (Section 5.4.1). It computes as if with unbounded range and precision, rounding only once for the final result.
-
If either or or is a NaN, return an element of .
-
Else if either or is a zero and the other is an infinity, then return an element of .
-
Else if both or are infinities of equal sign, and is a negative infinity, then return an element of .
-
Else if both or are infinities of opposite sign, and is a positive infinity, then return an element of .
-
Else if either or is an infinity and the other is a value of the same sign, and is a negative infinity, then return an element of .
-
Else if either or is an infinity and the other is a value of the opposite sign, and is a positive infinity, then return an element of .
-
Else if both and are zeroes of the same sign and is a zero, then return positive zero.
-
Else if both and are zeroes of the opposite sign and is a positive zero, then return positive zero.
-
Else if both and are zeroes of the opposite sign and is a negative zero, then return negative zero.
-
Else return the result of multiplying and , adding to the intermediate, and the final result ref:rounded <aux-ieee> to the nearest representable value.
4.3.3.8.
-
If either or is a NaN, then return an element of .
-
Else if either or is a negative infinity, then return negative infinity.
-
Else if either or is a positive infinity, then return the other value.
-
Else if both and are zeroes of opposite signs, then return negative zero.
-
Else return the smaller value of and .
4.3.3.9.
-
If either or is a NaN, then return an element of .
-
Else if either or is a positive infinity, then return positive infinity.
-
Else if either or is a negative infinity, then return the other value.
-
Else if both and are zeroes of opposite signs, then return positive zero.
-
Else return the larger value of and .